Security camera for a network

ABSTRACT

A method for processing data from a communication line. Data is received from the communication line ( 802 ) and segregated into packets ( 803 ). Packets are selected based on a respective characteristic ( 804 ) and the selected packets are provided to one of a plurality of data processing units.

This application claims the benefit of priority under 35 U.S.C. §119from U.S. Provisional Patent Application Ser. No. 60/203,652 filed May12, 2000, which is hereby incorporated by reference. PCT ApplicationPCT/US99/27969 is incorporated herein by reference.

TECHNICAL FIELD

The present invention relates generally to data communications, and, inparticular, to a system and related method for collecting, analyzing,and monitoring data communications.

BACKGROUND OF THE INVENTION

It is now routine for data and other information to be communicated todifferent points via a communications or data network. One example ofsuch data networks includes multiple end-user computers whichcommunicate with each other along the various paths comprising suchnetworks. The complexity of such computer networks can range from simplepeer-to-peer connection among a relatively small number of machines, toLANS, WANS and, of course, the global computer network known as theinternet. The architecture of such networks varies widely, depending onthe particular application, but most sophisticated networks make use ofbackbones, nodes, and computer servers supporting the transmission ofdata and information over such networks.

Companies and individuals are increasingly relying on such data networksnot only for sending and receiving information, but for transactingbusiness, and for any conceivable number of other activities involvingthe sending, receiving or viewing of information. The advent of theInternet and its continued development has only increased the demand foreffective communication among companies, individuals, and other users ofsuch networks.

This demand for sending and receiving data over such networks generatesso-called called “traffic”, that is, a volume or “payload” ofdigitally-encoded information traversing appropriate paths on thenetwork. Unfortunately, traffic across the network often leads tocongestion or “trouble spots” at certain points or along certain pathsof the network. Such congestion may take the form of maddeningly slowtransmission of data, or, at worst, a complete inability to send orreceive needed information over such network. This problem is compoundedby the fact that, under certain network architectures, the trafficgenerally proceeds only as quickly as its slowest link or pathway willallow.

Obviously, such traffic congestion is undesirable for any number ofreasons. Users “stuck” in such traffic may blame the congestion on theirnetwork service providers, causing such providers to potentially losebusiness. Such network delays will also have a negative effect, bothdirectly and indirectly, on productivity of the networks users.

One approach to relieving such network congestion or other network“trouble spots” is to obtain timely and accurate information about thecongestion or trouble spot. Unfortunately, attempts of the current artto unravel the intricacies of computer networks and relieve thecongestion suffer from various drawbacks and disadvantages. For example,network monitoring tools of the current art may be difficult tocustomize, and thus may lack the necessary tools to analyze networkcongestion or trouble spots. Such network “sniffers” are often limitedto performing traffic dumps of certain specific protocols which, again,may fail to accurately describe or pinpoint the source of networkcongestion. In other words, most network monitors and “sniffers” of thecurrent art are limited in their abilities to tabulate real-time data,or to record data over extended periods of time.

Network monitors of the current art generally intrude into the networkin order to evaluate or estimate network performance. The reference“TCP/IP Illustrated, Volume I—The Protocols,” Chapters 7 and 8,available from Addison-Wesley Publishing Co., 1994, describes one suchtechnique. To estimate round-trip times for “packets” of information inthe internet, the network monitor injects additional packets into thenetwork and follows the travel of such additional packets. Thus, thevery process of determining network performance itself further degradesperformance by adding additional packets of information to the traffic.

Not only is the above-described method intrusive, but it is generallyinaccurate as well. In particular, one-way times are evaluated bygenerally dividing the round-trip delay of the test packet by two;however, half of a round-trip time is generally not equivalent to aone-way delay, in part based on asymmetries (discussed below) in thenetwork. To compensate for this inaccuracy, certain teachings of thecurrent art inject test packets more frequently into the network, asolution which may farther degrade the performance of the network whichis being tested or monitored.

Network performance may be further enhanced if network traffic flow ornetwork bandwidth dimensioning could be more accurately modeled. Inparticular, traffic does not necessarily flow symmetrically across agiven network path. This is especially true when the path terminates inan end user on an internet connection. Such a path is asymmetric in thatthe end-user normally downloads more payload or traffic than he or sheuploads. Network monitors of the current art generally do not detect ormodel such asymmetries, with the result that greater network resourcesare devoted to particular routes than may otherwise be required. Thiscosts additional money and wastes computer resources.

There is thus a need to improve network performance and relieve networktraffic congestion. There is a further need for tools which do notintrude upon the traffic flow, which can be adapted to analyze differenttraffic parameters or types of “packets,” and which collect and tabulaterequired statistics quickly and accurately.

With the increasing use of computer data networks, companies andindividuals are increasingly interested in collecting, filtering, or“profiling” data about the users or their traffic on such networks.Marketing enterprises or other sales organizations may be particularlyfascinated by demographic or other data which can be gleaned by accuraterecording and analysis of network traffic. Unfortunately, many internetadvertisers obtain customer profiles by requiring the users to fill outforms and questionnaires, Advertisers miss out on most of this customerinformation because customers often do not want to be bothered withanswering such questions. There is thus a need to obtain customer“profiles” in a less intrusive manner.

The expanding use of networks has likewise expanded the possibilities of“hackers” or other damaging intruders performing mischief or evencriminal activities in proprietary or protected networks. As such, asystem which can determine the origin of security breaches would bevaluable to enforcement agencies, such as the FBI, to stem the tide ofcomputer-related crimes and misdemeanors. The current art, again,generally fails to analyze, tabulate, monitor, or record the flow ofdata over a network in an optimal way to facilitate security activities.

Companies or individuals charged with monitoring networks not only needto obtain vast amounts of information and statistics in a timely manner,but they also need to view such data quickly, easily, and in anunderstandable format. Again, current art solutions are often limited toproviding “dumps”, often chronologically, with inadequate statisticalcompilations or graphical representations of such data. It is thusdesirable not only to compile network traffic information, but toperform certain commonly needed calculations, and to graphicallyrepresent such calculations in a user-friendly and flexible format.

To overcome the shortcomings of conventional data communicationmonitoring methods and systems, a new method of monitoring acommunication line is provided. An object of the present invention is toprovide a network monitor for collecting and analyzing communicationdata. Another object is to provide a method for collecting and analyzingcommunication data.

SUMMARY OF THE INVENTION

To achieve these and other objects, and in view of its purposes, thepresent invention provides a method for processing data received from acommunication line. Data is received from the communication line andsegregated into packets. Packets are selected based on a respectivecharacteristic and the selected packets are provided to one of aplurality of data processing units.

It is to be understood that both the foregoing general description andthe following detailed description are exemplary, but are notrestrictive, of the invention.

BRIEF DESCRIPTION OF THE DRAWING

The invention is best understood from the following detailed descriptionwhen read in connection with the accompanying drawing. It is emphasizedthat, according to common practice, the various features of the drawingare not to scale. On the contrary, the dimensions of the variousfeatures are arbitrarily expanded or reduced for clarity. Included inthe drawing are the following figures:

FIG. 1 shows a network monitor according to the present inventioncoupled to a communication line;

FIG. 2 illustrates an exemplary protocol hierarchy;

FIG. 3 is a block diagram of an exemplary network monitor according tothe present invention;

FIG. 4 is a flow chart illustrating an exemplary method of monitoring acommunication line according to the present invention;

FIG. 5 is a data flow diagram illustrating the many permutations of datacollection and analysis methods of a network monitor according to thepresent invention;

FIG. 6 is a flow chart illustrating a method for identifying troubledservers;

FIG. 7 shows a network using network monitors according to the presentinvention coupled to two separate communication lines in a network;

FIG. 8 is a flow chart illustrating a method for determiningtransmission delay;

FIG. 9A is a flow chart illustrating operation of a host computer forsynchronizing with an interface computer;

FIG. 9B is a flow chart illustrating operation of an interface computerfor synchronizing with a host computer;

FIGS. 10-28 are screen displays illustrating a user interface forreceiving monitoring parameters and illustrating methods of displayingand providing communication analysis information;

FIG. 29 illustrates an exemplary network monitoring system according toan exemplary embodiment of the present invention;

FIG. 30 is a clock diagram illustrating a distributed network monitoringsystem;

FIG. 31 is a screen display illustrating a user interface forcentralized management of a hierarchical network monitoring system; and

FIG. 32 is a block diagram of a network monitor according to anexemplary embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Referring now to the drawing, in which like reference numerals refer tolike elements throughout, FIG. 1 illustrates an exemplary networkmonitor 102 according to the present invention which is coupled to anexemplary network N1 106 via a first communication line 104. The networkmonitor 102 receives (monitors) data communications (traffic) oncommunication line 104 and provides real-time metrics or statistics ofthe data traffic on the communication line 104.

The communication line 104 may use a single data link layer protocol totransport traffic of a multitude of different higher hierarchicalprotocol layer protocols. One such hierarchical protocol structure 200is illustrated in FIG. 2. The data link layer protocol 202, Ethernet inthis exemplary case, of traffic between the network N1 106 and therouter 108 may include encapsulated IPX IP, ARP, or other network layer204 traffic. The IP traffic may include encapsulated UDP, TCP, ICMP orother transport layer 206 traffic. The TCP traffic may includeencapsulated Web, FTP, Domain Name Service, or other application layer208 traffic.

The network monitor 102 according to the present invention includeshardware and software (discussed below) which collects and analyzesnetwork traffic in such a way that it can generate a variety ofreal-time statistics on such traffic at one or multiple protocol layers.The real-time statistics generated by network monitor 102 enable qualityand quantity of service analysis, billing based on quality of serviceand quantity of service, dynamic network resource allocation andplanning, customer profiling based on data content, network securityanalysis, and session playback. Exemplary statistics include bytecounts, bit counts, one-way or roundtrip delays, response times,retransmitted bytes, originating bytes per host, terminating bytes perhost, originating-terminating host pair counts, web abort rates,throughput, goodput, and percent retransmitted bytes due to delays orlosses. These statistics may selectively be provided based on traffic onthe first communication line 104 on one or multiple protocol layersbetween the data link layer and the application layer.

Operation of an exemplary network monitor 302 shown in FIG. 3 isdescribed with reference to the flow chart in FIG. 4. The networkmonitor 302 includes a first network interface 304 coupled to a firstcommunication line 308 by a first connection 312 and a second networkinterface 306 coupled to a second communication line 310 by a secondconnection 314. The first interface 304 receives first data (abitstream) from the first communication line 308 (step 402) and thebitstream is then segregated into packets (step 404). The term segregateis used herein to mean that previously defined packets are beingextracted from the bitstream. The bitstream may be segregated intopackets by either the interface 304 or by the host computer 316. Thepackets are stored in memory 318 which is hierarchical in thisembodiment and includes a short-term memory 320 and at least onelonger-term memory 322. A processor and query engine 316, optionallycontrolled by a user interface 324, then processes the packets asdescribed below with reference to FIG. 4.

In an exemplary embodiment, the network monitor 302 is coupled to thefirst communication line 308 in a non-intrusive manner. That is, it doesnot directly hinder the flow of traffic on the communication line. Thenetwork monitor 302 may be coupled to the communication line 308, forexample, by plugging the first connection 312 into a port or jack on aswitch or router, by breaking the communication line 308 and installinga Y-connector to which the first connection 312 is coupled, byconnecting the first connection to a hub, using an optical splitter, orby connecting the network monitor 302 to a monitoring jack in a centraloffice.

Processor and query engine 316 converts the packets into records andstores the records in memory (steps 414-422). Processor and query engine316 includes suitable programming to generate statistics correspondingto the packets (steps 406-412). Although the generation of statisticsfor the packets may be accomplished in a variety of ways, one preferredapproach processes a set of packets received over a predetermined timerinterval or “sampling time” (step 406) to generate correspondingstatistics (step 408). The processing is then repeated in a recursivefashion to successive sets of packets received during successive timeperiods (step 410). During such processing, suitable programming storesthe generated statistics in memory at appropriate intervals of time,such intervals preferably on the same order as the time intervalscorresponding to the sets of packets.

The conversion of the packets into records permits a wide variety offurther statistics to be generated as now described. The records aregenerated by first determining the type of each packet (step 414) andthen filtering the packets (step 416) based on their determined types.An index is generated (step 418) for each packet and the packet is thenconverted into an indexed record (step 420) and stored in memory (step422). Further statistics are then generated (step 426) using thestatistics previously generated for the packets and records are thenprovided to one or more applications such as a display device (step428), a router for dynamically adjusting network routing based on thefurther statistics (step 430), and a billing service for billing clientsbased on quality or quantity of service as determined based on thegenerated statistics (step 432).

Application of the process of FIG. 4 is now described for an Ethernetcommunication line including encapsulated IP packets which encapsulateTCP packets which encapsulate web traffic (See FIG. 2). The Ethernetbitstream is received from the communication line (step 402) and issegregated into packets (step 404). The packets are divided into sets,each set including packets received during one of successive one-secondtime periods (exemplary time period) (step 406). The number of bitsreceived during each one-second time period (exemplary statistic) iscalculated (step 408). Successive statistics are generated forsuccessive time periods by receiving the next set of packetscorresponding to the next one-second time period (step 412) and thencalculating the number of bits in those packets (step 408). The bitcounts for each one-second time interval are stored in memory (step 412)as they are generated.

A type (e.g. IP, ARP, . . . ) of each packet is determined (step 414).If a user only wishes to analyze traffic of IP packets, the packets arefiltered to pass only the IP packets (step 416). The time when thenetwork monitor received each IP packet is used as an index for the eachrespective IP packet (418). An indexed record is then generated (step420) for each IP packet and is stored in memory (step 422). An exemplaryrecord having the index as a first field F1 and the packet as a secondfield F2 is illustrated below.

F1: Index (time of receipt) F2: Packet or portion of packet

In addition to the filtering (step 416) only passing IP packets, thefilter may also be used to pass only a portion of the packet, such asonly the IP portion, by truncating the Ethernet overhead portion so therecord above contains only the IP portion in the second field F2.Alternatively, the record may include a plurality of fields, eachcorresponding to a portion of the IP packet such as a source address ordestination address, and filtering may be performed based on any one ormore of the plurality of fields.

Any number of statistics can be generated from the stored records alone,or in combination with statistics for the packets generated in steps46-412. In this example, a further statistic known to the art ofinterest includes the ratio of the number of bits in IP packets receivedto the number of bits in all packets received for each successive minute(step 426). The calculation of this statistic is facilitated accordingto the present invention, because the stored packets are already all IPpackets and are indexed by time of receipt. As such, the calculation isperformed by sorting the records by index, reading the set of recordsfor each successive, minute, and adding the number of bits in each setof records. The number of bits in all packets per minute may becalculated by summing the previously calculated bit counts generated ona per second basis in groups of sixty (thereby equaling one minute).Thus, the further statistic is generated using both the stored recordsand the stored statistics, which reduces the number of additionalcalculations needed and the time to generate such further statistic.

A specific example of the filtering and storing methods performed by anetwork monitor according to the present invention was described abovewith regard to FIG. 4. The flexibility of data collection and analysismethods of a network monitor 500 according to the present invention aredescribed below with regard to the data flow diagram of FIG. 5.

An incoming bitstream is packetized by a packetizer 502. Decoding of thebitstream may be automatically performed for known protocols or may beperformed according to user-specified parameters for custom orproprietary protocols. For example, if a new data link layer protocol isintroduced, network monitor 500 includes suitable programming to respondto user-defined protocols, entered using the user interface 520. Theinventive network monitor 500 thus recognizes packet structures of thenew protocol to packetize an incoming bitstream. The network monitorcould then perform its data collection and analysis methods through thehigher protocol layers. This flexibility is not limited to the data linklayer. In other words, the network monitor 500 according to the presentinvention is able to collect and analyze data communications for customprotocols at other protocol layers.

The packets may be directly stored into the short-term memory 510 usingpath A. This is useful for storing all data received from thecommunication line. The short-term memory 508 may periodically transferdata to a long-term memory 510 to prevent overflow. Although illustratedas having only a single short-term memory 508 and a single long-termmemory 510, the teachings of the present invention are applicable toother hierarchical memory structures including a plurality of memorydevices. For example, the memory may include a random access memory(RAM), a disk memory, and a tape memory. As the RAM fills, data istransferred to the disk memory. As the disk memory fills, data istransferred to the tape memory. As the tape memory fills, tapes arereplaced for continuous or long-term data storage for archival purposes,for example. As indicated by the double arrow to the short-term memory508 and between the memories 508, 510, data stored in the memories maylater be retrieved for analysis or for one of the applications 522-530discussed below.

Storing all packets directly into memory may be desired for securityapplications 528. For example, the network monitor may be programmed tostore all communications for a period of 1 week and then overwrite theoldest stored data. If a breach in security is detected within a week ofits occurrence, the stored data may be analyzed by the network monitorto determine the source and extent of the breach.

The packetized data may alternatively be provided by the packetizer 502to the index generator 504. The index generator 504 generates an indexcorresponding to one or more of the received packets. Examples of anindex corresponding to a packet include a time stamp to indicate thetime it was received by the network monitor, the type of packet(protocol and/or layer), the size of packet, a packet number (1, 2, 3, .. . ), an interface number, an application, and an associated session.Record generator 506 receives the packets and the generated index andgenerates a record including the generated index. Alternatively, therecord generator 506 may combine the received packet and index with anexisting record previously stored in memory 508, 510. The recordgenerator may also receive a packet directly via path C and generate anunindexed record including the packet or may combine the packet into anexisting record previously stored in memory 508, 510.

For example, a single record may be generated corresponding to an ATMsession. When a first cell (a fixed size packet) corresponding to theATM session is received, it may be indexed and an indexed record maybegenerated and stored in the memory 508, 510. The index may be anidentifier of the ATM session, for example. When further cellscorresponding to the ATM session are received, not necessarily in order,the record generator 506 may directly receive these cells via path C,read the previously stored indexed record from memory 508, 510, and thencombine the newly received cell into the indexed record in addition tosimply combining packets belonging to a common ATM session in a commonrecord, the record generator 506 may also orient the received ATM cellswithin the record in their correct order.

The record/packet type identifier 512 receives packets or records fromeither the record generator 506 or from the memory 508 and thencharacterizes the received packets or records by identifying itscorresponding “type” or “property”. The type or property of a packet orrecord is a versatile identifier and may be programmed via the userinterface 520. Examples of packet or record types or properties includethe number of corresponding bits or bytes, its protocol layer, itsprotocol type at a particular protocol layer, a source address, adestination address, an end-user ID, and an application ID. The recordsor packets are then filtered in the packet type filter 516 based on theproperty or type identified by the record/packet type identifier 512.The filtered records or packets are then indexed, indexed and turnedinto records, or directly stored into memory 508, 510.

The time period filter 514 receives records or packets from the recordgenerator or the memory 508, 510, and filters them based on the timethey were received from the communication line by the network monitor.The records or packets are then segregated into groups corresponding topackets received by the network monitor during respective successivetime periods. The statistic generator 518 then generates statistics foreach of the successive time periods corresponding to packets receivedduring each respective successive time period.

The filtered packets and the generated statistics may be stored inmemory. The paths between the functional blocks in FIG. 5 illustratethat the contents of memory may then again be used to perform furtherfiltering or statistic generation. Thus, a network monitor according tothe present invention may recursively collect and analyze data bygenerating statistics based on previously generated statistics or storedpackets.

In addition to programming the network monitor for a custom protocol asdescribed above, the user interface 520 may also define the operatingparameters of the functional blocks within the network monitor. Forexample, a user may specify the index to be used by the index generator504, the time period to be used by the time period filter 514, and thestatistics to be generated by the statistic generator 518 for each ofthe successive time periods.

The collected data and the corresponding analysis generated by thenetwork monitor 500 may be provided to one or more applications 522-530.For example, a display device 522 may display statistics, records orpackets responsive to user selection as further described below withregard to the display screens in FIGS. 10-28.

The statistics generated by the network monitor 500 may be provided to anetwork administrator or router 524 to allow for dynamic routing ofcommunications and network bandwidth management, also known as “yieldmanagement”, on a network responsive to statistics corresponding tonetwork performance. It is readily appreciated that, by measuringone-way delays and by providing traffic statistics on aprotocol-by-protocol basis at different protocol layers, a networkmonitor according to the present invention can identify theseasymmetries by quantifying traffic flows to allow a networkadministrator to properly size network resources according to themeasured flows.

Communication networks can be optimized at the service layer because thenetwork monitor according to the present invention includes suitableprogramming to analyze traffic flows at any protocol layer. Althoughdifferent services may have different service requirements, theseservices are often integrated in a single communication network.Nonetheless, services such as real-time multimedia, voice over IP, data,and Intranet may each have unique network service requirements. Forexample, for voice over IP, due to low tolerances in voice transmissionsdegradation, a lower quality of service including delay or loss of datamay not be tolerated. In contrast, data transmission can proceed in alossy environment due to error recovery by retransmission. An exemplaryrouter 524 is configured to route tragic corresponding to differentservices differently depending on their service requirements.

The network monitor according to the present invention includesprogrammed features which identify flows corresponding to eachindividual service and/or user and provide for analysis of interactionswith different services. This information may be used by a router, forexample, to make real-time or non-real-time decisions on optimizingnetwork topologies, routes, or service segregation, etc. to achieve anoptimal configuration suitable for providing each and every service withits own unique quality of service requirement.

A billing system 526 may be configured to receive quality and/orquantity of service statistics corresponding to different services anddifferent hosts and bill clients accordingly. This allows clients to bebilled based on these statistics rather than providing flat rate billingfor previously unmeasured service. For example, a client may use herunlimited Internet service for voice over IP communication. According tothe present invention, the network monitor 500 may generate statisticsfor a particular client on the number, duration, and destination ofvoice over IP calls. The statistics are then converted to billinginformation by the billing system 526 and the client is billedaccordingly. Thus, an Internet subscriber that uses the Internet forvoice over IP calls, may now be billed according to the quantity,duration, and destination of calls as is done for non-Internet telephoneservice. Clients may similarly be billed based on a number of e-commercetransactions, a number of stock trades, a number of requests forreal-time stock quotes, and other transactions. Alternatively, clientsmay have service contracts including different billing rates dependingon a quality of service provided and may be billed accordingly. Anetwork monitor may also be used to ensure compliance with servicecontracts which guarantee minimum service standards or service levelagreements.

As described above, the collected data may be used for security 528 toidentify breaches in security, to identify improper network use orillegal activity. For example, packets may be filtered to identifyparticular files which have been FTP'd to a server, to identify whotelnetted (logged onto) a particular machine or server, and to see whatthey typed once logged on.

Statistics from a network monitor may be correspond to a user or a groupof users for profiling the user or group. Much Internet advertising isdirected to customers based on a customer profile generated by asking auser to answer a few questions. A network monitor according to thepresent invention can filter each received packet based on its contentsto build individual customer profiles. For example, a node whichmonitors the Philadelphia customer base may look at every packet fromevery user before it enters the Internet. Also, the returned traffic tothese users can be analyzed by looking (filtering) for specific textwithin the packets or for the web sites visited by the user. A profileper user or group of users may then be generated based on the filtereddata to target content to the user which will be of interest to the usersuch as targeted email. The method described above for filtering maysimilarly be used by law enforcement or security officials to monitorcommunications to detect unlawful activity or to monitor activity ofselected users.

The network monitor may also be used to provide data to a playbackdevice 530 to playback client sessions which were monitored from thecommunications line. All received packets may be recorded and thenfiltered based on a particular session. The session may be identifiedbased on information included in the packets themselves or based onsession information received in special packets or channels such as SDR(session directory protocol). The packets corresponding to the sessionmay then be played back in a fashion originally presented to the user.This method may be used to replay all web activity of a user or of voiceover IP conversations.

The network monitor may be configured by a user to monitor communicationlines that transport traffic using a proprietary or custom protocol.Along with a suitable physical layer interface between the networkmonitor and the communication line, a user may enter proprietaryprotocol parameters using the user interface. The parameters define thestructure of packets within the bitstream transported on thecommunication line for the network monitor to segregate the packets fromthe bitstream. Additional parameters may also define fields within apacket so the network monitor could be configured with custom queries toprovide statistics based on the content of these packet fields. Thenetwork monitor may similarly be programmed to receive and analyze datacorresponding to custom protocols at layers higher than the link layer.

In an exemplary network, the data transmission protocol provides foreach packet to include a time stamp field. Packets transmitted from asource to a destination include a time stamp value in the time stampfield indicating a time of transmission by the source. When the packetis received at the destination, the destination can compute the one-waytransmission duration or delay from the source to the destination bysubtracting the time stamp value from a current time value. Thisprotocol allows for simpler one-way transmission delay and quality ofservice measurements by eliminating the need for communication betweennetwork monitors to match packet pairs at separate network monitors.

For a network including many separate intermediate transmission pathsbetween the source and the destination, the one-way end-to-endtransmission duration information does not provide information regardinga particular bottleneck somewhere between the source and destination.For improved bottleneck diagnosis, rather than only calculate end-to-enddelays, a network monitor according to the present invention can becoupled to one of the intermediate separate transmission paths betweenthe source and destination. The network monitor can receive the timestamp value from a packet traversing the network from the source to thedestination. The time stamp value may be subtracted to the current timeat time of receipt of the packet by the network monitor to determine anintermediate duration value. One or more intermediately spaced monitorsmay be used as described above to locate the bottleneck in a network. Inan exemplary embodiment each of the source, destination, and networkmonitor include a GPS (global positioning satellite) interface forreceiving the current time used to calculate the transmission duration.

One of the metrics that a network monitor according to the presentinvention can provide is an indication of the number of abortedconnections for a particular source-destination pair, for a particularsource or destination, and information on the ration of abortedconnections to total connections for a particular source or destination.An exemplary method of identifying troubled TCP (transmission controlprotocol) servers is described with regard to the flow chart 600 in FIG.6.

As known to those skilled in the art, a TCP session is normally openedby the client and is then closed by the server when it has no more datato send to the client. If a TCP session is closed by the client, thisindicates that the session is being terminated prematurely. Using theweb as an example, a client (user using browser) may close the sessionfor reasons including simply changing one's mind regarding the need forthe desired data or due to impatience due to delay in receiving desireddata.

The network monitor receives a packet from a communication line (step602) and identifies whether the packet belongs to a TCP session (step604). The network monitor may identify whether the packet is a TCPpacket by identifying and decoding a protocol field in the packet whichidentifies which of several transport layer protocols the packet belongsto. Once a packet is identified as TCP, the TCP client and TCP serverare identified (step 606). The packet is then examined to determinewhether it opens or is initiating the TCP connection (step 608). If thepacket is the opening or initiating packet of a TCP session, a count ofthe total number of TCP sessions for the previously identified (in step606) TCP server is incremented (step 610).

If the packet is not an opening packet, the network monitor nextdetermines whether the packet is closing the TCP connection (step 612).If not, the network monitor gets the next packet (step 602). Otherwise,the network monitor determines (step 614) whether the connection isbeing closed by the server, by examining the FIN bit for example, orwhether the connection is being closed by the client. Closure by theserver indicates normal termination of the session and the networkmonitor gets the next packet (step 602). Closure by other than theserver indicated premature termination of the session and a prematureclosure count corresponding to the particular server is incremented(step 616). The ratio of premature closures to the total TCP sessions ofthe particular server is calculated (step 620) and compared to apredetermined threshold value (step 622). If the ratio of prematureclosures exceeds the threshold, the particular server is identified as a“troubled server” (step 624).

As known to those skilled in the art, in some networks all packetscorresponding to a particular TCP session may not travel through thesame communication line and therefore may not be detected by a singlenetwork monitor interface. A network monitor can be placed in proximityto or on a server or client to “catch” all packets. Alternatively,multiple network monitor interfaces may be used as described above tostore records corresponding to packets. The stored records may then beanalyzed to determine which servers may be “troubled”. In an exemplaryembodiment, remote network monitors each look for FIN packets, using afilter, for example, and upon detecting a FIN packet they send a messageincluding the contents of the FIN packet to a central monitor that makesthe “troubled server” determination.

Although the teachings regarding measuring aborted connections andidentifying troubled servers are described above with regard to TCPsessions, these teachings are generally applicable to other protocolsand to other protocol layers and are not limited to identifying troubledTCP servers. For example, in another protocol, a session may be bothopened and closed by the same node, whether it be the client or theserver. In addition, the session payloads may be transmitted in separatepackets from or on separate communication links from the session controlmessages.

In a further alternative embodiment shown in FIG. 7, a system 701 formonitoring communications according to the present invention may includeone or more networks monitors each coupled to respective communicationlines in a network as shown in FIG. 7. First, second, and third networkmonitor 700, 710, 720 are coupled to the first, second, and thirdcommunication lines 702, 712, 722, respectively. Each network monitor700, 710, 720 collects and analyzes data received from its respectivecommunications line as described above with regard to the data flowdiagram in FIG. 5.

In addition to providing independent data collection and analysis, asystem including a plurality of network monitors 700, 710, 730 maycorrelate data received at the different network monitors to provideimproved network performance analysis. For example, one-way delay may becalculated for data traveling from the first communication line 702 tothe second communication line 712.

An exemplary method of calculating the one-way delay is illustrated bythe flow chart in FIG. 8. Generally, the “same” packet is identified attwo separate network monitors and the difference in time between when itwas received by each monitor is used to calculate the one-way delay. The“same” packet is identified by zeroing out portions of the packet thatchange between the separate network monitors.

Each of the first and second network monitors 700, 710 receives data(step 802, 806) from its respective communication line 702, 712. Thepacketizer 502 segregates the received data into packets (steps 803,807) and each the index generator (504) associates the time of receipt(time stamp) of each packet with each packet. The record generator 506generates a record including the time stamp of corresponding to eachpacket and a unique portion of the data packet (UPDP) and stores therecord in memory 508, 510 (steps 804, 808).

The UPDP is a portion of the received packet that makes the data unituniquely identifiable. For example, for an Ethernet communications lineand an IP payload, the Ethernet header is removed from the packet, theIP ttl and checksum fields are zeroed, and the IP header and the 20succeeding bytes are saved and incorporated by the record generator 506into a UPDP record. The UPDP may be different for different protocolsand may be programmed using the user interface.

The UPDP records of the first network monitor 700 are compared to theUPDP records of the second network monitor 710 to match pairs of UPDPs(step 810). The first and second network monitors may communicate via acommunication link 730. The communication link 730 may be implemented bycommunication of the network monitors through the network they aremonitoring (in-band). Alternatively, the communication link 730 may beimplemented by communication external to the network over a telephoneline, a radio connection, or a satellite connection, for example(out-of-band).

For each matched pair of UPDPs, the corresponding time stamp ts2 fromthe second network monitor is subtracted from the corresponding timestamp ts1 from the fit network monitor (step 812). This time differencets1−ts2 represents the duration for the data corresponding to the UPDPto travel from the second network monitor 710 to the first networkmonitor 700. By calculating the UPDP, the transmission duration of acertain payload between first and second communication lines 702, 712using the same or different communication protocols may be determinedaccording to the method described above.

In an exemplary embodiment, the time difference ts1−ts2 is normalized(steps 814, 816) to account for the delay of the first communicationline 702. The delay is normalized by subtracting the delay xmit-delayfor the packet corresponding to the UPDP to traverse the firstcommunication line from the time difference as illustrated by theequation below:Normalized Network Delay=(ts1−ts2)−(link_speed/packet_length)

where link_speed is the transmission rate on the first communicationline 712, and packet_length is the length of the packet on the firstcommunication line which contained the UPDP. The calculated networkdelay may include components due to queuing delay and to transmissiondelay. As illustrated by the data flow diagram in FIG. 5, the statisticgenerator 518 can receive the packet for which is UPDP record is to begenerated, the statistic generator 518 calculates the number of bits inthe packet and provide this statistic to the record generator forincorporation into the UPDP record for use in a normalizationcalculation. Round-trip times may be estimated by similarly calculatingthe delay from the first to the second network monitor and adding thisdelay to the delay between from the second to the first network monitor.

The accuracy of the calculated transmission delay depends on thesynchronization of the time clocks of the first and second networkmonitors 700, 710. The network monitors may communicate viacommunication line 730 to synchronize their respective clocks. In anexemplary embodiment, the network monitors are synchronized by receivinga time signal from a common time source 740. In an exemplary embodiment,the transmission delay is generated at a level of accuracy less than 10microseconds, that is, the difference between the calculated delay andthe actual delay is less than 10 microseconds. In a preferredembodiment, the common time source 740 is a system of global satellitessuch as the global positional satellites (GPS) and each network monitor700, 710 includes a receiver for receiving a time signal from one ormore global satellites. When the two communication lines to be monitoredare proximate to each other, one of the first and second networkmonitors 700, 710 may include a master GPS receiver and the other mayinclude a slave GPS receiver coupled to the master.

An exemplary network monitor is implemented with a host computer havingan interface computer on a network interface card (NIC) coupled to thecommunication line it is monitoring. As described above, data receivedby the NIC may be processed before being sent to the host computer. Alsoas described above, the network monitor may use the time of receipt ofdata from the communication line for generating network communicationstatistics or metrics. In order to accurately record the time when datais received from the communication line, the interface computerassociates a time of receipt with the data (time stamps the data). Byhaving the interface computer rather than the host computer time stampthe data, inaccuracies in the time of receipt due to a delay intransferring data from the interface computer to the host computer arereduced or eliminated.

In an exemplary embodiment, the interface computer includes an interfaceclock and the host computer has a host clock. The host clock and theinterface clock are synchronized so the host computer can use the timestamp to accurately generate statistics corresponding to the receiveddata. In an exemplary embodiment, the interface clock is implemented asa counter. As each packet is received from the communications line, thecurrent value of the counter is associated with that packet. The packetis later transferred to the host computer with the counter value. Thehost computer includes a host clock synchronized with an absolute timereference. As described above, the absolute time reference may beprovided by a global positioning satellite.

The host clock and the interface clock are synchronized by correlatingthe counter values associated with each packet by the interface computerwith the absolute time reference. The method of synchronizing theinterface clock with the host clock is described with reference to theflow charts in FIGS. 9A and 9B with regard to the host computer and theinterface computer, respectively. Generally, the host computerperiodically requests the value of the interface clock counter from theinterface computer and uses this value to correlate the counter to thehost clock.

Referring to FIGS. 9A an 9B, if the host computer has received a set ofpackets from the interface computer (step 902), the host computerproceeds to request the counter value to (step 906) from the interfacecomputer by sending a “get counter” message to the interface computer.In an exemplary embodiment, the interface computer stores a set ofpackets in a memory of the host computer by a direct memory access (DMA)operation and then interrupts the host computer to indicate the transferof packets. If the host computer has not received a set of packets, thehost computer waits for packets for a timeout period (step 904), afterwhich it requests the counter value (step 906). The host computerrecords the host clock's time (step 906) when it requests the interfacecounter value.

When the interface computer receives a “get counter” message (step 920)from the host computer, the interface computer then determines (step922) whether it is currently idle or whether it is receiving data fromthe communication line. If not idle, the interface computer sends (step924) a “try again” message to the host computer. If idle, the interfacecomputer then reads the counter value and subtracts a precomputedinterrupt service time (step 926) to generate an adjusted counter value.The interface computer then sends (step 928) the adjusted counter valueto the host computer.

The precomputed interrupt service time corresponds to the duration oftime between when the interface computer receives the counter requestfrom the host to when the interface computer provides the host computerwith the adjusted counter value. The precomputed interrupt service timemay be determined experimentally using a logic analyzer, for example tomeasure the duration of time between when the interface receives therequest for the counter until the interface provides the counter value.To match the experimental delay measurements to the delay during normaloperation, the experimental request is provided to the interface whenthe interface is known to be idle and the interface only services arequest during normal operation when idle. As known to those skilled inthe art, the response time of the interface computer may be takenrepeatedly to generate an average service time for use during operation.

Upon receipt of the counter value, the host computer computes (step 912)an estimate of the relative frequency of the interface clock counter tothe host computer clock. The relative frequency may be used tocorrelating counter values associated with packets received to from theinterface computer until the next execution of the synchronizationroutine. In an exemplary embodiment, the host computer subtracts a hostinterrupt service time from the time recorded in step 906 beforecomputing the relative frequency to account for the delay between thetime when the host receives the count from the interface to the timewhen the host computes the relative frequency.

In an exemplary embodiment, a multiple network interfaces each coupledto a respective communication line are implemented as a single unit andshare a common clock. Thus, synchronization with only the common clocksynchronizes the host clock with the time stamps associated with datareceived from any of the respective communication lines.

FIGS. 10-28 are exemplary screen displays illustrating a graphical userinterface (GUI) for displaying data collected and analyzed by a networkmonitor and for controlling data analysis by a network monitor accordingto the present invention. The display in FIG. 10 includes a tables frame1010, a second frame 1030, and a buttons frame 1050. The tables frame1010 includes a first portion 1011 with selectable boxes for userselection and text input boxes and a second portion 1012 with tables ofstatistics corresponding to received data. The tables 1023 which appearbelow the selectable buttons, boxes and fields include entriescorresponding to the particular data being analyzed. The plots frame1030 includes plots 1032, 1034 illustrating statistics corresponding toreceived data. The buttons frame 1050 includes a set ofuser-configurable buttons.

The text input boxes and the selectable boxes in the first portion 1011of the tables frame 1010 may optionally be fixed to prevent userselection of the options and prevent user entry in the text boxes. Thefunctions associated with the options and boxes displayed in FIG. 10 aredescribed below:

-   -   1. Start: The start field 1013 specifies the beginning time from        which the traffic is analyzed and its results are displayed in        the GUI.    -   2. Stop: The Stop field 1014 specifies the ending time to which        the traffic is analyzed and its results are displayed in the        GUI. Thus the Start/Stop fields 1013, 1014 specify the time        between which the traffic has been analyzed and presented to the        user via the GUI. The contents of the Start and Stop fields        1013, 1014 may be displayed in multiple formats. For example,        the contents are shown in a date format in FIG. 10.        Alternatively, the contents may be displayed as +/− hours to        indicate that a time relative to the current time, the term        “now” may be used to represent the current time, or the term        “never” may be used to represent that the data should be        continuously updated.    -   3. Window: The Window field 1015 indicates the time intervals at        which to compute values to be plotted in the second frame 1030.        For example, if a user enters “1” as the Window field, then the        values in the plot field are plotted every second The user may        enter the values in the Window field in using units as        appropriate to indicate the resolution of the plots (e.g. 1 s, 1        ms, 100 us, . . . to indicate a time resolution if the unit of        the horizontal scale is time). An empty Window field 1015        indicates that the resolution on the horizontal scale should be        automatically set.    -   4. Top N: The Top N field 1016 specifies the maximum number of        entries for the tables 1023 which appear in the second portion        1012 of the tables frame 1010. If Top N is 10, then the table        1023 will include 10 rows sorted by a particular column value in        descending order. If TopN is −10, then the table 1023 will        include 10 rows sorted by a particular column value in ascending        order (i.e. this becomes the notion of BottomN).    -   5. Filter. The Filter window 1017 describes a filter to be        applied to the data to be displayed. For example, Filter could        be “protocol IEEE802.3” to display results for packets with link        layer protocol IEEE802.3. For data previously filtered to show        only IP traffic, a Filter of “host 10.0.0.1” would display        results for IP traffic where either the source or destination        host was 10.0.0.1. Various complex filters are also possible.    -   6. Do DNS: The Do DNS checkbox 1018 converts entries in the        tables 1023 from a numerical representation to a textual        representation. For example, in IP a numerical representation        (the IP address) is used to identify a host. A DNS (Domain Name        Server) may contain a mapping from this numerical representation        of the IP address to a textual representation. For example, the        IP address 10.0.0.1 may be converted to the textual        representation foo.niksun.com when the Do DNS checkbox is        checked. For protocols other than DNS the label given to the        checkbox will vary accordingly with an equivalent fuctionality.    -   7. Help: The help buttons 1019 next to each field when selected        cause display of context-sensitive assistance. For example, if        the help button next to Filter 1017 is selected, a help window        for Filters would pop up.    -   8. Refresh: The Refresh button 1020 refreshes the contents of        all frames.    -   9. Forward and Backward Buttons: The forward 1021 and backward        1022 buttons at the top of first portion 1011 of the tables        frame 1010 function similar to the “forward” and “Back” buttons        of a browser with the added feature of keeping the contents of        all frames aligned. In contrast, clicking the “Forward” and        “Back” buttons of a browser causes forward of backward movements        on a frame by frame basis hence loosing correspondence between        the various frames.

The plots frame 1030 includes plots 1032, 1034, text input boxes andselectable boxes and buttons. The text input boxes and the selectableboxes may optionally be fixed to prevent user selection of the optionsand prevent user entry in the text boxes. The functions associated withthe options and boxes displayed in the plots fame 1030 of FIG. 10 aredescribed below:

-   -   1. Update Tables and Plots: This button 1036 updates the tables        and frames in a coordinated manner. For example, if a user zooms        in by selecting a portion of the plot with a mouse, then        clicking this button 1036 would update the plots and tables for        the selected time range that was zoomed into.    -   2. Byte/Packet Counts (and Bit/Packet Rates) (and Utilization):        This button 1037 changes between one of three options upon        selection: “Byte/Packet Counts”, “Bit/Packet Rates”, and        “Utilization”. The plots also change from Byte/Packet Counts        over a certain window, to Bit and Packet Rates (i.e. number of        bits or packets per second), to Utilization accordingly. In an        exemplary embodiment, the byte plot displays normalized values        relative to the link speed (i.e. bit rate divided by link or        channel or virtual circuit capacity in bits per second).    -   3. Toggle Parent Plot: This button 1038 toggles the line on the        plots as described below.    -   4. Toggle Plot of Average: Selection of the Toggle Plot of        Average button 1039 toggles whether the average value (not        shown) of the y-axis of the plots is displayed.    -   5. Play/Forward/Stop/Fast Forward/Rewind/Fast Rewind/Pause        Buttons: These buttons 1040 control the playing of the plots on        the screen to allow the plots to be updated over time and to        scroll with time. The tables 1023 in the table frame 1010 are be        updated to match the plots 1032, 1034.    -   6. Top Plot: The top plot 1032 shown in FIG. 10 is a Link Level        Bit Rate plot in bytes/second.    -   7. Bottom Plot: The bottom plot 1034 in FIG. 10 is a Link Level        Packet Rate blot in packets/second.

The table 1023 in the tables frame 1010 is automatically generated basedupon protocols found to be active in the interval specified by the Start1013 and Stop 1014 fields. In FIG. 10, the table 1023 shows that betweenthe Start and Stop times, 264K (K=1000's) IP packets and 919 ARP packetswere received by the network monitor. The IP packets and ARP packetscontaining 99M and 55K bytes, respectively (M=1,000,000).

The entries in the table 1023 are selectable to sort data by theselected field. For example, if the packets heading in the table wasclicked then the table would be sorted by the packets column indescending order of activity and if this header is clicked again, thenit would be sorted in the opposite order. Selection of the other tableheadings similarly sorts the entries.

FIG. 11 illustrates the zooming capability of the present invention. Thestart/stop time interval of 7:18/12:02 in FIG. 10 is narrowed to the9:00/10:00 time interval in FIG. 11. The table 1023 and plots 1032, 1034have been updated accordingly. The start 1013 and stop 1014 field valuesmay be adjusted by either manual entry in the fields 1013, 1014themselves, or by graphical selection, by a mouse for example, of aninterval of time in the plots 1032, 1034. Upon selection, the displaywill zoom into the selected interval. Zooming in on the plots causes theplots to be regenerated for the interval selected by the user. Selectionof the “Update Tables and Plots” button 1036 will then synchronize datain the tables frame 1010 to the plots 1032, 1034. The plots could alsobe updated automatically, if the user selected the “auto-synch” feature(not shown). The “Update Tables and Plots” button 1036 allows a user tozoom in several times to a desired time interval without updating thedata. This provides the advantage of reducing unnecessary processing bythe network monitor until the final interval is chosen.

The protocols listed as entries in the table 1023 in FIG. 10 areselectable by a user, as hyper-links, for example, to list protocolsencapsulated within the selected protocol. Clicking or selecting the IPentry in table 1023 in FIG. 10 results in the display of FIG. 12. Theselection causes the plots 1032, 1034 in the plots frame 1030 of FIG. 10to automatically update to show only IP traffic in plots 1232, 1243 inFIG. 12.

The plots illustrate al traffic from the link layer as a line chart 1235and all IP traffic as a bar chart. This dual-display format provides agraphical representation of the perspective between all traffic of onelevel (IP in this case) compared to all traffic of a previous level(Ethernet in this case).

The contents of the tables in the tables frame 1210 are also updated tocorrespond to IP traffic. Table 1223 lists all IP protocols which werein use on the link being monitored between the “Start” and “Stop” times.In this particular case, only TCP, UDP and ICMP IP protocols were found.Activity by IP hosts may also be displayed. By scrolling down the tableframe 1210, the table of IP counts by source host is seen as illustratedin FIG. 13 for the case where TopN=2.

In FIG. 13, traffic is displayed in a source host table 1302 for trafficgenerated by hosts, in a destination host table 1304 for trafficreceived by a host, and in a host table 1306 for traffic generated andreceived by a host. Clicking on a link 1308 in the tables frame 1310will generate a display of a “host-pairs” table 1402 shown in FIG. 14.

The host-pairs table 1402 lists the total number of packets and bytessent between pairs of hosts for each identified pair.

Selection of a “destination host” such as 10.0.0.47 (1404 in FIG. 14)will further filter the traffic by the selected “destination host” toshow only traffic destined for host 10.0.0.47. This is illustrated inFIG. 15 where table 1502 shows traffic destined to 10.0.0.47, all fromhost 128.32.130.10 in this case for traffic monitored between the startand stop interval.

Thus, we see that only host 128.32.130.10 was sending traffic to10.0.0.47 between the “Start” and “Stop” times. Note that the plots1532, 1534 in the plots frame 1530 now show this activity between thesetwo hosts as a bar chart 1535 and all IP traffic as a line chart 1536.Colors may also be used to distinguish the data in the plots or tables.

If the TCP entry in table 1223 in FIG. 12 is selected, we move up theprotocol stack and the tables frame 1610 is updated as shown in FIG. 16to include TCP level counts for each underlying application 1612. Forexample, there were 27K HTTP (web) packets which contained 21 MegaByteswhich were received during the designated time interval.

In FIG. 16, if the “TCP flows” button 1604 is selected, all TCP flowsare displayed with their time durations and performance metrics as shownin FIG. 17. A TCP flow contains a set of packets belonging to one TCPsession between two hosts. Each flow may be plotted or its correspondingpackets viewed by selecting the “plot” button 1702 or the “pkts” button1704, respectively, corresponding to the desired TCP flow. Note that ifthe Do DNS option had been selected, all TCP host IP addresses would bereplaced by their respective names (e.g. foo.niksun.com). A user mayaggregate flows by clicking on other links such as the ones thatidentify a particular host such as 10.0.0.47. If a user clicks on10.0.0.47 (1706), aggregated flows for host 10.0.0.47 will be displayedas shown in FIG. 18.

FIG. 18 shows all TCP flows originating from host 10.0.0.47. The displayin FIG. 18 is generated by applying a filter selective to the 10.0.0.47host to the data displayed in FIG. 17. Further filters can similarly beapplied by clicking on other hosts (hyperlinks) in FIG. 18. For example,in the “Term host” column, if a user selects host 10.0.0.5 (1802), thenall TCP flows between host 10.0.0.47 (as source) and host 10.0.0.5 (asdestination) are displayed.

A “TCP performance” selection may be provided, in the screen display ofFIG. 16, for example, for generating TCP performance tables. By clickingon the “TCP performance” hyperlink, performance tables 1902 for TCP aredisplayed as shown in FIG. 19. The whole tables frame is displayed inFIG. 19 or clarity, The display includes a “Troubled TCP Clients” tableand a “Troubled TCP Servers” table for the worst two performing TCPclients and servers (TopN field value of 2). Over the time intervalspecified by the Start and Stop fields, the tables show the followingmeasurements for each TCP client or server:

-   -   1. No. of Connections: This is the total number of TCP        connections to the client or server.    -   2. TCP Data Bytes: This shows the total number of data bytes        carried by all the TCP connections.    -   3. TCP goodput (Bytes/sec): This shows the TCP payload        throughput (application throughput) or TCP goodput. That is, the        total number of application bytes divided by time it takes to        send these bytes averaged over the number of connections.    -   4. TCP throughput (Bytes/sec): This shows the total number of        bytes carried in the TCP connections divided by time (TCP flow        rate).    -   5. Avg RTT: This shows the average Round Trip Time between the        client and server over the number of connections.    -   6. Avg Response: This shows the average response time from the        server to the client.    -   7. Retransmit %: This shows the percentage of TCP bytes which        were retransmitted (due to congestion, loss, or delay, or any        other reason).

The TCP performance tables may be customized to add other metrics ordelete existing metrics via the user interface.

Selecting the http hyperlink in FIG. 16 results in the display ofstatistics for web traffic (http) as shown in FIG. 20.

An “http performance” selection may be provided, in the screen displayof FIG. 20, for example, for generating http performance tables. Byclicking on the “http performance” hyperlink, performance tables 2102for http are displayed as shown in FIG. 21. The whole tables frame isdisplayed in FIG. 21 for clarity. The display includes a “Troubled WWWClients” table and a “Troubled WWW Servers” table for the worst twoperforming WWW clients and servers (TopN field value of 2).

The metrics in the http performance tables 2102 may be generated onlineand displayed to the user as troubled www clients and www servers or maybe fed directly to a network management system for immediate action.These metrics can help a network administrator to identify bad serversand connections. This format may also be used to as the basis to notifythe web server operator to buy more bandwidth or to fix his server.Further, it can be used to nod clients that they may need more bandwidthor they may need to choose another service provider. Accordingly, thesemetrics may be used to improve the quality of service given to users andultimately may provide further revenue to the network administrator. Forexample, in the table “Troubled WWW Servers”, the second server listed(204.162.96.10) had about 33% web aborts. This could indicate apotential loss of 33% of the customers from this web site.

The tables frame 1610 is updated as shown in FIG. 16 to include TCPlevel counts for each underlying application 1612. For example, therewere 27K HTTP (web) packets which contained 21 MegaBytes which werereceived during the designated time interval.

Upon selection of the UDP hyperlink 1240 in FIG. 12, we move up theprotocol stack and the display of FIG. 22 is provided to illustratelevels of UDP traffic. In the tables frame 2210, a “UDP Level Counts”tables is displayed showing activity for each UDP application or UDPport. For example, the display indicated that there were 453 domainpackets which contained 69 KiloBytes.

Note that UDP bandwidth usage was only about 0.32% of the total IP (seetable 1223 in FIG. 12). Thus, the plots frame shows only IP traffic (REDgraph) which dwarfs the UDP traffic (in BLUE). By clicking on the“Toggle Parent Display” the user can now zoom the Y-axis only on the UDPtraffic (this is not illustrated) as the plot for IP (parent plot) willbe removed.

Selection of the “MBONE” button 2202 in FIG. 22 results in display of anapplication layer analysis of MBONE (Multimedia backbone) sessions asshown in FIG. 23.

Selection of the ‘View Packets’ button 2204 in the buttons frame 2250 inFIG. 22 gives a dump of all packets as shown in FIG. 24. Since thenetwork monitor can record all packets, all packets and their contentscan be viewed. The links in the display of FIG. 24 allow a user toflexibly filter the data streams. If the user clicks on 10.0.0.12(2402), then the next screen of dumps will only contain packets to andfrom 10.0.0.12. In that next screen, if a user selected 10.0.0.5, thenthe updated display would show only packets between 10.0.0.12 and10.0.0.5. A user could also further qualify the dump by selecting ports.Various options for dumping packets can be applied by selecting a typeof dump from the selections 2404 at the top of the screen display.

Selection of the “Recommend” button 2206 in the buttons fine 2250 ofFIG. 22 results in the display of real-time capacity or bandwidthrecommendations for the network Upon detection of selection of the“Recommended” button 2206, the network monitor uses a mathematical modelto interpret the data being viewed by the user to providerecommendations on bandwidth usage by an application (or other types oftraffic) or on setting of link/switch capacity to obtain a specificquality of service. Several such statistics 2502 are shown in FIG. 25. Auser may enter desired quality of service values such as loss rates andmaximum delays to obtain recommendations on the capacity required tosupport the desired quality of service for the type of traffic analyzed.FIGS. 25 and 26 illustrate the recommendations which can be provided.

In an exemplary embodiment the user may select a particular applicationand a “busy-period” for which she wants to “size” the network resourcesfor a particular quality of service level. Appropriate subroutines inthe network monitor then analyze the particular application traffic andextract or estimate “model parameter”. Using the mathematical model, andestimates of the parameters, as well as parameters of quality of service(such as packet loss rates, network delays, frame rates, etc.) the modelcomputes statistics such as statistical multiplexing gains, capacityrequirements, and buffer allocations and provides the user with optimalrecommendations of switch/router configurations, network resources, orserver parameters to maximize network utilization while meeting thequality of service requirements. Such recommendations can be computed ona real-time basis where the statistic is updated for every packet or aset of packets belonging to different services and feedback can beprovided to network elements along the path for each flow on optimalconfigurations to enable dynamic resource allocation to meet servicequality requirements.

The x-axis 2602 of the graph represents the number of users and they-axis 2604 represents capacity a bits/second. For a desired number ofus the capacity can be read off the chart or from a display ofcorresponding tabular results. FIG. 27 illustrates a display similar tothat in FIG. 22 for the case where the Do DNS button was selected so theIP addresses are solved to their registered names.

FIG. 28 is a display showing statistics that are displayed uponselection of the “Statistics” button 2208 in the buttons frame 2250 inFIG. 22. Upon selection of the “Statistics” button 2208, the networkmonitor computes various statistics based on data currently being viewedby the user. Exemplary statistics include packet size distributions,protocol distributions, bandwidth usage per client, bandwidth usage bydomain, average response time per server, average round-trip timebetween server-client pair, and performance metrics.

The present invention is not limited to a particular division offunctions between the host computer and the interface computer. Thefunctions of the host computer and the interface computer may beperformed by a single computer. Interface with a network monitoraccording to the present invention is not limited to the user interfaceand may be via the network being monitored or another communicationline.

FIG. 29 illustrates an exemplary monitoring system including a networkmonitor 2902 NetDetector), which is coupled to a first communicationline 2904 via a tap 2906. The network monitor 2902 receives (monitors)data communications (traffic) on communication line 2904 and selectscertain packets from the data based on the characteristics of thosepackets. The network monitor 2902 then provides the selected packets toone of a plurality of data processing units 2908, 2910, 2912. Thenetwork monitor can immediately provide received packets to the dataprocessing units or may store and later retrieve the packets accordingto filtering criteria. The received packets may be selected based on oneor more of a source address, a destination address, a packet type, anautonomous system, a source port, time, a destination port, a networkidentifier and a pair of hosts, for example.

This architecture allows a network monitor 2902 which has a largethroughput and large volume storage capacity to perform a dataprocessing function in parallel for each of several selected groups ofpackets using data processing units 2908-2912 that have a throughputcapability less than that of the network monitor 2902.

In an exemplary embodiment, the data processing units 2908, 2910, 2912are intrusion detection systems (IDSs). The network monitor 2902provides groups of selected packets to each IDS to allow the system toscan for intrusions with a higher throughput than a single intrustiondetection system.

The system may optimize the intrusion detection system based on thecriteria for selecting packets that am received from the communicationline. In an exemplary embodiment, the network monitor does this byeither recording sessions on a storage media and playing back sessions(or flows, e.g., TCP/IP flows—SYN-FIN) over to different IDS devices; orby streaming sessions directly from network capture devices to outputinterface(s) or data processing units which may be under the same ordifferent protocal as on the communication line or may be in anencrypted format.

A session may be identified as all packets from SOURCE IP→DEST IP oreverything from one SOURCE IP or Network or TCP flow between a pair ofhosts or HTTP flow between a pair of hosts or UDP packets from one hostor Network, for example.

The system provides improved detection of port scans over a system thatrandomly select packets for distribution to the different dataprocessing units or IDSs by selecting all packets corresponding to portscans for a single port for distribution to a particular IDS. This alsoimproves the ability of the system to identify port scans or addressscans which can occur at slow or fast rates; networks, hosts from whichDenial of Service or distributed denial of service attacks took place;anomalous traffic or “behavior” from hosts or users compared tohistorical (time of day, day of week—to set standard or thresholds)activity; fake or unusual transactions in e-commerce, e.g., suddenactivity to transact trades on the stock exchange for different usersfrom one IP address. For example, data on a communication line may beprocessed by: (a) receiving the data from the communication line; (b)segregating the data into packets; (c) selecting packets based on arespective characteristic; (d) generating a statistic corresponding tothe selected packets; (e) generating a threshold based on historicalvalues of the statistic; and (f) generating an alarm signal if thestatistic exceeds the threshold. The statistic may correspond, forexample, to the number of packets received for modifying a key file.

FIG. 30 illustrates a hierarchy of network monitors for monitoring anetwork. The hierarchy allows for centralized management of the networkmonitoring system from a single interface. A user can view a network ofnetwork monitors and their hierarchical relationship to each other. Anyunit in the network can be configured and traffic statistics can beviewed from a unified user interface.

Centralized Management allows for the unified configuration and accessof multiple network monitor (NetVCR) nodes from a single interface.Network Monitors are arranged in an ancestor/descendant hierarchy,ancestors maintain information about their descendants, and descendantsreport their status (and the status of any of their descendants) totheir immediate ancestor. The Centralized Management interface allowsfor easy viewing of all descendant nodes, and provides access to TrafficAnalysis and network monitor configuration interfaces.

When a new network monitor is added to the network it needs to beconfigured with the IP address of its immediate ancestor to begin theregistration process. The new descendant network monitor registers withthe ancestor node, supplying information about itself and itsdescendants. The ancestor will create a record of the descendant (ordescendants) in its database. After registration, the descendantperiodically sends a keep-alive message to its immediate ancestor. If adescendant is removed from the system the ancestor will no longer bereceiving signals from that descendant and the ancestor will set thestate of that descendant to down (offline).

FIG. 31 illustrates a centralized management interface of a hierarchicalnetwork monitoring system. Centralized Management provides a “familytree” view of the NetVCR network. The interface graphically shows thehierarchical relationship of the various NetVCR units. The tree view canbe expanded one level at a time, allowing the user to drill down theNetVCR network hierarchy.

The left pane of the interface contains the NetVCR Tree View. It issimilar in format to a file manager's representation of directories,subdirectories and files. The Tree View has three tabs across the top,Analysis, SLA, and Alarms. In FIG. 31, only the Analysis tab isimplemented. At first the Tree View is fully collapsed, meaning thatonly the root node is visible in the tree. Double-clicking a node willexpand it one level, revealing the node's immediate descendants.Double-clicking the node again will collapse the branch.

The icon to the left of each node name indicates its role in the NetVCRnetwork. An icon of a globe indicates an ancestor node, and an icon of acomputer indicates a descendant-only node. If the icon turns red thenthe node is currently of fine or the communication link between thedescendant and ancestor has been lost.

A single-click on a node populates the Network Traffic Data Table, tothe right of the Tree View, with information about the datasets on thatnode. The table provides the following information:

Recorded On: The hostname of the NetVCR that recorded the dataset.

Interface: The interface type of the dataset

Status: The recording status of the dataset. It can have one of thefollowing four values: Recording, Stopped, Archived Recording andArchive Stopped (refer to Chapter 3 for the definition of each term).

Comment: The Dataset Name of the dataset as defined in the DatasetConfiguration Page.

Data Start and Data Stop: The start and stop times of the dataset.

Device: The physical interface used for recording traffic data

At the bottom of the Network Traffic Data Table are two buttons thatenable horizontal and vertical grid lines on the table. Once a datasethas been selected from the Network Traffic Data Table, the DatasetOperation Menu to the right of the Data Table is used to specify theparameters of the data to be displayed. These fields and buttonscorrespond to the controls for dataset analysis.

Start and Stop: The time interval that is desired for analysis. Refer toChapter 4 of the User's Guide for details on specifying time intervals.

Protocol Layer: A pull-down menu list of the protocol layers availablefor analysis (including Frame, Link, IP, TCP and UDP).

Analyze: Clicking on this button connects to the NetVCR Analysis Pagefor the selected dataset, using the parameters set by the Start, Stop,and Protocol Layer fields (refer to Chapter 4 in the User's Guide formore details on this feature).

Configure: This button connects to the NetVCR Dataset Configuration Pagefor the selected dataset (refer to Chapter 3 in the User's Guide formore details on this feature).

Reports: Clicking this button will connect to the NetVCR Reports Pageand allow the user to view Standard and Custom reports.

Schd. Reports: This button connects to the NetVCR Report ConfigurationPage for the selected dataset and the chosen protocol layer.

An Autonomous System (AS) is a group of IP networks operated by one ormore network operator/s, which has a single and clearly defined externalrouting policy. A user-specified filter may be used to define theautonomous system. For example, a valid qualification could be (net121.097.0.0 mask 255.255.0.0) or (121.099 mask 255.255.0.0) or (net121.100/16).

A distributed network monitor allows for correlation and aggregation ofdata across the network. This allows for tracking of events (e.g.,hacker or cracker activity) across the network (to the source). This iseffective due to accurate time stamps across interfaces.

A network monitor can scans for patterns indicative of an intruder: portscans on all entry points; telnet attempts on all entry points; patternsindicating denial of service attack, patterns indicating coordinateddenial of service attacks; modifications to key files that may indicateinsertion of a back door into a system.

A network monitor may be used to:

-   -   Providing a “request for Action” notification to shut down the        point(s) of entry. This action could be accomplished via an        intelligent agent, modifications to the ACL, or via an Operator.    -   Determination of whether “back doors” have been created.    -   Providing a “Request for Action” notification to close any        additional entry paths that have been created by the hacker.        This action could be accomplished via an intelligent agent or an        operator.    -   Display history of the hacker's actions.    -   Providing records of any files downloaded to the breached        system.    -   Identification of what has been compromised and providing a        “Request for Action” notification, thus enabling the        Administrators to take actions to “undo” the damage done.    -   Providing detailed information on the culprit for prosecution,        i.e. an “evidence trail”.

The specific applications that can be supported via NetDetector include:

-   -   Scanning for patterns indicative of an external intruder and        alerting administrators of the possibility of attack in        progress.    -   Scanning for patterns of misuse of corporate resources by        internal personnel    -   Working cooperatively with a first line of defense system        already deployed within the network to identify whether the        intrusion is still in progress; whether back door have been        created; what has been compromised and details about the        culprit.    -   Working cooperatively with an intelligent engine capable of        self-learning to continuously expand and improve the alarm        patterns.

A network monitor according to the present invention can set thefollowing thresholds for detecting anomalous activity:

-   -   For a particular set of applications, the number of IP host pair        connections involving a common IP address (either the source or        destination) exceeds x over a time window of y. x and y should        be user configurable. The set of applications should include a        set of positive rules, e.g. telnets and pings, as well as        negative rules such as “not http”.        This can be used to track Denial of Service attacks and IP host        scans.    -   For a particular IP host pair, the byte rate exceeds x or over a        sustained period of y. x and y should be user configurable. The        set of applications should include a set of positive rules, e.g.        telnets and pings, as well as negative rules such as “not http”.

This can be used to track suspicious “excessive” usage to a destinationfrom a particular source. For example, break-ins to a particular host.

-   -   For a particular IP host, the number of individual sessions        exceeds x or over a sustained period of y. x and y should be        user configurable. The set of applications should include a set        of positive rules, e.g. telnets and pings, as well as negative        rules such as “not http”.

This can be used to track suspicious “excessive” session activities to adestination from a particular source. For example, break-ins to aparticular host.

-   -   The utilization of the monitored link exceeds a rate x and is        sustained for a period of time y. x and y should be user        configurable.        This can be used to track Denial of Service attacks.    -   A packet with an invalid source or destination IP address        traverses the monitored link. (This can be done if you can        statically specify a set of “valid” IP source addresses that        comprise the end network cloud.) For unidirectional links,        source and destination can be separately checked. For shared        mediums like Ethernets, one could only trigger an alarm if both        source and destination addresses are invalid.        This could check for spoofed addresses.

Check for a generic byte pattern in the payload. This feature would scanselected packets (filtered traffic) for a match of a user-defined bytepattern.

Alarming Features

A SNMP trap can be sent to a connected management system when athreshold is exceeded. In addition, alarming could also be provided toJanus to show alarms on the web-based interface (much like when one hasreceived an email).

GUI/Configuration Features:

A user can configure the necessary parameters for threshold checkingThis means that the x's and y's as specified above are user-specifiableas well as other information needed to define the threshold, e.g. listof “valid” source and/or destination addresses.

-   -   V Ability to identify a single IP host that has initiated        “excessive” amounts of connections with other IP hosts    -   Ability to specify the time span, the number of connection        attempts that qualifies as excessive and the frequency of        attempts which should be considered excessive    -   Ability to identify single DP to IP connections with an        excessive amount of ports being used in the connection    -   Ability to determine when network activity is exceeding “normal        thresholds” (bandwidth spikes for extended periods)    -   Ability to specify the time span and height of the spike which        would be considered excessive    -   Ability for the user to specify a list of “valid ports” and        alarm on any connection attempts to ports not specified    -   Ability to alert the network administrator in the event of        suspicious activity    -   Ability to provide audio and visual alarms on the network        administrator's screen    -   Ability to provide the administrator with maximum flexibility on        alerts (e.g. pager; cell phone; e-mail)

Architectural Overview

FIG. 32 shows the basic architecture of the NetDetector system:

The Control Module communicates and directs the actions of all the otherNetDetector components (shown as ovals). These are:

-   -   Activity Detector: Network activity & Pattern Recognition module    -   Data Manager: Data Archive & Export Module    -   Alerter: Alert Module

The Configuration Module configures the control module. Theconfiguration module is responsible for the Pattern Recognition DatabaseSDB), from which the patterns to be detected, and actions to be takes amread by the Activity Detector.

The Alert Module is responsible for generating alerts according toconfigured action parameters. The alerts can occur in various forms,selected by the user, such as: SNMP traps, Email, Pager, or Console.

The Data Manager has two components: the Archive Module and the ExportModule. The Archive Module is responsible for saving packet datarelevant to the alerting event so that the normal aging process does noterase it. The Export Module manages the transmission of relevant data toexternal systems for father analysis,

By detecting sudden peaks in network tic that last for more than aspecified duration, NetDetector can signal when possible DoS attacks arein progress. In addition, keeping track of unresolved SYN requests andICMP echo request packets is another way of detecting potential DoSattacks.

A network monitor according to the present is self-learning to enablerealize when increased network activity has become the norm without thenetwork administrator specifying the change.

-   -   Regular expression search in email (SMTP/POP analysis), web        pages (HTTP analysis), and other application level messages        (e.g. FTP, TELENET).    -   Interoperability with external Intrusion Detection Systems.

Although illustrated and described above with reference to certainspecific embodiments, the present invention is nevertheless not intendedto be limited to the details shown. Rather, various modifications may bemade in the details within the scope and range of equivalents of theclaims and without departing from the spirit of the invention.

1. A method for processing data from a communication line comprising thesteps of: (a) receiving the data from the communication line; (b)segregating the data into packets; (c) selecting packets having datawith a common characteristic; (d) for every selected packet identifyinga particular one of a plurality of parallel intrusion detection devicesbased on the common characteristic; and (e) providing the selectedpackets to the particular parallel intrusion detection device.
 2. Amethod according to claim 1 further comprising the step of storing thesegregated packets and step (c) includes selecting stored packets havingthe common characteristic.
 3. A method according to claim 1 wherein step(a) includes receiving data under a first protocol and step (e) includesdistributing the selected packets under a second protocol different fromthe first protocol.
 4. A method according to claim 1 wherein the commoncharacteristic is a session.
 5. A method according to claim 1 whereinthe common characteristic is one or more of a source address, adestination address, an autonomous system, a source port, a destinationport, a network identifier and a pair of hosts.
 6. A method according toclaim 1 wherein the common characteristic is a first characteristic andthe method further comprises: selecting packets having data with acommon second characteristic where the second characteristic isdifferent from the first characteristic; for each selected packet havingthe common second characteristic identifying another particular one of aplurality of parallel intrusion detection devices based on the commonsecond characteristic; and providing the selected packets having thecommon second characteristic to the other particular parallel intrusiondetection device.
 7. A method according to claim 6 wherein the first andsecond characteristics are different characteristics selected from thegroup of session, source address, a destination address, an autonomoussystem, a source port, a destination port, a network identifier and apair of hosts.
 8. A method for processing data from a communication linecomprising the steps of: receiving the data from the communication line;segregating the data into packets; selecting packets having data with acommon characteristic; encrypting the selected packets; for eachencrypted selected packet determining a particular one of a plurality ofparallel intrusion detection devices based on the common characteristic;and distributing the encrypted selected packets to the particularparallel intrusion detection device.
 9. A method for processing datafrom a communication line comprising the steps of: receiving the datafrom the communication line; segregating the data into packets; selecting packets in at least one first time interval based on arespective characteristic; generating a statistic corresponding to theselected packets in the at least one first time interval; generating athreshold based on the statistic corresponding to packets in the atleast one first time interval; generating a statistic corresponding topackets in a second time interval, the second time interval definedbased on the first time interval; and generating an alarm signal if thestatistic corresponding to packets in the second time interval exceedsthe threshold.
 10. A method according to claim 9 wherein the statisticcorresponds to a number of packets of different users received from onesource address.
 11. A method according to claim 9 wherein the statisticis a count of packets received for modifying a key file.
 12. A methodaccording to claim 9 wherein the statistic corresponds to a number ofhost pair connections involving a common source or destination address.13. A method according to claim 9 wherein the statistic corresponds to apacket rate corresponding to a host pair.
 14. A method according toclaim 9 wherein the statistic corresponds to individual sessionscorresponding to a host.
 15. A method according to claim 9 wherein thestatistic corresponds to utilization of the communication line.
 16. Amethod according to claim 9 wherein the statistic corresponds to anumber of invalid source or destination addresses.
 17. A method forprocessing data from a communication line comprising the steps of:receiving the data from the communication line; segregating the datainto packets; identifying a respective characteristic of each packet;selectively providing every packet to one of a plurality of parallelintrusion detection devices in response to its respective identifiedcharacteristic; and detecting an intrusion based on packets in multiplesessions using a single one of the parallel intrusion detection devices.18. A method according to claim 17 wherein the characteristic is asession.
 19. A method according to claim 17 wherein the characteristicis based on at least one of a source address, a destination address, anautonomous system, a source port, a destination port, a networkidentifier or a pair of hosts.
 20. A method according to claim 17wherein the packets are selectively provided to the plurality ofparallel intrusion detection devices such that the packets which have acommon characteristic are provided to the same intrusion detectiondevice.
 21. A method for processing data from a communication linecomprising the steps of: (a) receiving the data from the communicationline; (b) segregating the data into packets; (c) selecting packetshaving a common characteristic; (d) providing the selected packets toone of a plurality of parallel intrusion detection devices; and (e)detecting an intrusion using the one of a plurality of parallelintrusion detection devices optimized responsive to the commoncharacteristic.